There's already docs and instructions for something like this: https://github.com/ferdikoomen/openapi-typescript-codegen/blob/master/docs/custom-request-file.md

Looks like the dev has possibly abandoned this repo though, there are breaking bugs that havent had attention in months.

There's already docs and instructions for something like this: master/docs/custom-request-file.md

Having to re-implement whole request logic means that there is a very high chance of things breaking on new version of this package being released.

This change looks like it would be a lot less prone to that.

Although ideally there would be some axios-client-specific method that one could override like createAxiosInstance so that it would be even more future proof but I imagine that would need more refactoring and potentially more axios-client-specific logic.

There's already docs and instructions for something like this: master/docs/custom-request-file.md

I've mentioned this method in the docs i've added. But as @rchl mentioned, that process is very error-prone, and when attempting it I ended up copying hundreds of lines of code from the default generated version of request.ts

Would really love to this merged as well.
My use case has a very carefully configured axios client going through a application-level proxy (not a standard HTTP proxy).
The complexity of copying all the code from the default request.ts file made me give up and opt for a different openapi client generator instead.
It would be really nice if this got merged and I could re-consolidate my openapi clients.

@yehonatanz
Which API generator did you go with instead?
Curious as this hasn't had any updates in a while

@yehonatanz Which API generator did you go with instead? Curious as this hasn't had any updates in a while

@blipk this one with the typescript-axios generator selected.
Pretty versatile, but has the distinct disadvantage of being written in Java and requiring a JRE to run (also I find it generates a more awkward interface, but that's a matter of taste I guess)

Would love to see this merged - as others have already mentioned, this is a blocker for some people using customised axios instances. Anything we can do to help this along? Is this implementation considered a viable option, or do the maintainers have a different view of how this should be implemented/handled?

Copying and overriding the request file won't do the trick in my case, since I am generating a client used by multiple projects, each of them having the need to pass in a custom axios instance when they generate the client (setting default custom headers etc.)

I am also looking for this functionality, thank you!

@ferdikoomen any chance this can be merged in? it's a relatively simple change, and it seems like it addresses a common pain point

Would be awesome to see some movement on this, such a small change but such a big impact 🙏

thank you @ferdikoomen for merging this PR 🎈

Does this work for non-named clients too (--name is not used), where all we have is static public functions in our generated services/clients?
We don't instantiate the client, so we don't have a way to:

const client = new GeneratedClient({ BASE: 'http://localhost:8123' }, AxiosHttpRequestWithRetry)

@ferdikoomen ref #942 I don't think that this implementation solves all cases when needing to provide a custom axios instance, since the axios instance instantiation can only occur inside the BaseHttpRequest override, it results in a too tightly coupled solution.

The axios instance would be better provided as an injected dependency in the constructor, so that we can create and pass in the instance from anywhere.

I am forking this repo to solve the problem, with backward compatibility, I'll create a PR and would be great if it could be considered to merge